====================================================================== IBIS INTERCONNECT MODELING AD HOC TASK GROUP MEETING MINUTES AND AGENDA http://www.eda.org/ibis/adhoc/interconnect/ Mailing list: ibis-interconn@xxxxxxxxxxxxx ====================================================================== Next Meeting Wednesday, December 3, 2008 8 AM US Pacific Time Telephone Bridge Passcode 916-356-2663 3 923-3240 (for international numbers, contact Michael Mirmak) LiveMeeting: https://webjoin.intel.com/?passcode=9233240 Agenda: - Call for patents - Opens - Final Touchstone 2.0 feature approval ====================================================================== Minutes from November 19: Attendees: ---------- (* denotes present) Agilent - Radek Biernacki*, John Moore, Ken Wong Ansoft - Denis Soldo Cadence Design Systems - Terry Jernberg, Brad Griffin Green Streak Programs - Lynne Green Hewlett-Packard - Rob Elliott* Intel - Michael Mirmak* Mentor Graphics Corp. - John Angulo*, Vladimir Dmitriev-Zdorov Micron Technology - Randy Wolff Sigrity - Sam Chitwood, Raymond Y. Chen, Tao Su, Brad Brim SiSoft - Walter Katz Teraspeed Consulting Group - Bob Ross* ======================================================================== No patents were announced. During opens, Bob noted that he held some offline discussions, during Which some suggested that blocking of data into an information section might remove need for [Number of Frequencies]. Michael asked whether a meeting would be held next week. No objections were raised. Michael called for comments on the current draft Touchstone 2.0 specification. Bob noted that, if we create an information block, it should appear at the very end, of the specification, even past the noise parameters, instead of putting elsewhere in the main documents. Port Groups would be moved within this block. Michael asked whether Interconnect Port Groups is similar to IBIS measurement parameters? Bob responded that this was a tough analogy; agreed on the basis of it being a throwaway keyword. Example: a distinction is made by some vendors that a database can be symmetrical or reciprocal. The off-diagonal terms are equal in a reciprocal network. Therefore, the matrix format keyword can be used to reduce (almost) half of the existing data. Symmetrical means the network can be "flipped" end-for-end, meaning that S11 and S22 can be identical. Therefore, some mathematical tests could be used to determine the actual data arrangement, and may conflict with the given port arrangement. SPICE connections to Touchstone files are widely used as a connection mechanism. Bob advised that this external connection to the file should override anything within the file. Rob observed that VNAs measuring differential transmission lines and feeding that into StatEye do not require a SPICE-style connection. Bob revised his earlier comments to suggest the actual [Begin Information]/[End Information] contents in any Touchstone 2.0 file should appear after [Version] and [Number of Ports] but before any data blocks. John added that the arrangement in both cases makes sense. Radek suggested that the file contents may be overridden by user decision, as proposed above, based on how the SPICE connections are made. This would make the information section and port arrangement acceptable. Michael noted that no actual header section is mentioned in the specification. Should the group define a header section? In addition, could a math-intensive parser can be defined for passivity and symmetry checking, making the interconnect port groups a parsable non-comment data set? Radek answered that parsing could be done but asked whether it is the job of the parser to make an interpretation of data usage? Can port names, as a keyword, accomplish the same Interconnect Port Groups task? What is meant by "parsable comment"? Earlier discussion on the reflector may have outlined a useful approach. Radek added that "the data is the data." For whatever reason, the data may not fit the other assumptions in the keywords. Rob responded that this is the reason why some are asking for the keyword. Bob clarified that the keyword is not always applicable and not always required. In IBIS, many keywords are required (related to measurement). If it isn't required, it should be assumed not to exist. In tools, you might have a manual display to help connect the data. Tools may adjust data called "passive" that really isn't. Bob added that putting in "passive, causal, reciprocal" into a file will not change whether the data actually defines an amplifier. Michael suggested that "parsable comment" means the keyword is defined by the specification and is checked for consistency with other keywords, but may be ignored. Radek responded that some vendors may use it, some may ignore it but this is not the purpose of a standard. We may already have unstructured comments. Bob answered that this data might be usable if it exists. Radek added that, if a user sees the data and keywords causing one behavior in one tool and different behavior in another, the standard is not operating as a standard. Bob summarized that Touchstone 2.0 compliance means to the 8 required keywords; informational keywords would be optional. Source data may not have been generated with the additional keywords supported (VNA); or, a model-maker may choose not to put it in. No tool is expected to support all or even any of the keywords in the information section. External connections (such as S-elements in some SPICE implementations) will override internal information. Bob added that the options include defining bracketed phrases as keywords, but leave the contents free-form (and tool-specific), or define rigid rules for keywords within the information section. Bob noted that Walter's position appears to be to enforce consistency between the information block and other keywords elsewhere in the file. If no rules exist, industry rules may be enforced by individual user groups. Radek commented if other groups own the problem, they should be able to define the format of the information. Rob added that comments today can convey the information, but the point of the keyword is to contain parsable information without the requirement to use it. Bob answered that industry-level keyword definitions would not necessarily check each others' keyword entries as parsable comments. Rob suggested that bracketed keywords offsetting noise data are a highly useful addition for StatEye (to prevent crashes) Michael asked the team bluntly whether they were individually accepting of having a [Begin Information] /[End Information] block with parsable, defined contents to be left to a future revision. Bob answered that he would prefer not to have the data there at all, but can live with this format. Radek asked why not have it outside the block, if it's rigidly defined? If left to users to include or not, he would be fine with that. Bob asked how to handle unknown text in that section. The team agreed that this was not a free-form area, if it's controlled by the specification. John added that the committee has to control what goes inside the keyword block, but it's understood that these would be special-use. We want parsers not to choke. For major revision, perhaps the in-block keywords can be promoted. Revision of the parser would be a bigger undertaking. A block defines usage for a smaller community. Bob suggested making the section an appendix B in the specification. The information block would be defined later, per Walter's proposal to pull out the interconnect port groups section. Bob asked about removing the [Number of Frequency] keyword, as raised in the opens. Radek stated that this would make allocating memory and parsing less convenient, which are the primary purposes for the [Number of Frequency] and similar keywords. Bob agreed to drop the Suggestion. Bob asked about data blocking. This will be covered at the next meeting. Filename extension rules will also be closed at the next meeting. AR: Bob to provide draft text of [Begin Information]/[End Information] section ======================================================================== Team Objectives: 1) complete ICM-IBIS linking BIRD and any associated changes to the ICM specification 2) update the ICM specification, if needed, to clarify the mapping of ICM nodes to S-parameter ports 3) complete a specification for "Touchstone Plus" or similar industry-standard definition for Touchstone-like files, to include complex impedance references, removal of limits on the maximum number of ports and per-port impedance references ------------------------------------------------------------------